Design Doc
Game: Crystallite Team: Nova Joel Sitte : Producer (RTIS) Wesley Pesetti : Associate Producer (RTIS) Alex Wilkinson : Physics Developer (RTIS) Jordan Logan : Graphics Developer (RTIS) Oland Pelton :Engine Developer (RTIS) Alex Troyer : Technical Director (RTIS) Erik Zeiger : Engine Developer (RTIS) Shane Pierce : Graphics/UI Developer (RTIS) Ryan Masserman: ''Art and Original Design (BAGD) ''Aviva Schecterson : Design Lead/Master, Level Designer (BAGD) Jasmine Rider : UI/UX Designer, Backup, Everything Else (BSCSGD) Adam Rehberg : Design Code Monkey (BSCSGD) Kiera Schroeder : Fine Arst Design Monkey (BAGD) Ryan Scott : Sound Design Lead (Music and Sound Design Student) Ryasa Harris : Sound Effects Designer (Engineering and Sound Design Student) High Concept Crystallite is an Isometric action-adventure in which players take control of Crystal Raiders to smash their way through hordes of enemies for glory, power, and riches. - Core Mechanics Movement Players will move relatively quickly across maps and screens, with the player character feeling rather quick when compared to Gauntlet or Binding of Isaac. The player should have a nearly unlimited rotational speed; they should have no trouble attacking in any direction at any time. The player should be constantly moving while fighting; there should never be a point where a player is able to dispatch a large group of enemies while standing still or moving in a simple straight line. This behavior will be encouraged by enemy types/specific weaknesses. - “Press to Swing” Style Combat Combat will be relatively simple, with basic attacking consisting of the majority of the primary action loop. The average enemy should only take one or two hits to kill, with only the most powerful opponents taking three or more hits. Each weapon type will vary slightly in it’s behavior, but none should deviate too far from a simple “point-and-swing” strategy. Weapons will deal their damage in an arc or zone, the size and shape of which vary based on the category of weapon being used. All combat is performed through only the trigger buttons (or mouse buttons, for keyboard controls) by holding down the button for varying amounts of time. Attack Cooldown Swinging the weapon should require at least some commitment to the attack; Each swing should be a rapid animation with a cooldown to prevent spamming, and to add a feeling of weight to the strikes. It's important for this cooldown to be long enough that players' don't feel rewarded by spamming their attack, but short enough that their attacks don't feel sluggish. Knockback Each swing should have at least some physics effect on nearly any object it touches, either displacing it in some direction, or simply smashing it into pieces. If an object is destroyed, any particles that are created should be sent flying in the direction of the player's swing. Objects that aren't destroyed should be visibly impacted. Knockback should be something we consider in all aspects of the game. Certain weapons should be able to bat away enemy projectiles. Players should be able to abuse knockback to trap tougher enemies into a corner, or to knock an enemy back and forth between each other to keep him stunlocked. - Positional Skills The majority of the skills players use will be less focused on the players' facing, and more on the players' position in the room. This will allow us to shift the focus of combat to a quicker-paced, almost more haphazard state in which players don't feel punished for recklessly attacking in all directions. - Enemies Enemies will consist of Popcorn, Grunts, Elites, Captains, Minibosses, and Bosses. Each enemy will fall into one of these five categories, which are expanded upon within the subsection. Enemies should generally be non-threatening unless in hordes, and take three or less hits to kill. The player should kill dozens of enemies for every would they suffer. Secondary Mechanics Weapon-as-Class Rather than selecting a class or combat type prior to the start of a Game Run, players’ fighting style is determined by whatever items they currently have equipped. This allows players to determine on the fly which fighting style will be most effective for the current challenge; more importantly, it will help stop gameplay from becoming stale by adding variations to the player’s primary action loop throughout play. Weapon types should start with major differences (melee vs ranged) and then - through iteration - be expanded to include more nuanced differences (thrown vs fired, blunt vs bladed) which will allow for a greater range of variety between weapons. Weapons will also be responsible for giving the player their skills. Weapons should be a semi-rare drop, taking a back seat to gold, power-up, and experience drops. Because weapons have the potential to completely change a player’s fighting style, their dispersion should be limited. Players are also likely to actively ignore many weapons one they've found a weapon/weapon type they like, meaning that too many weapons will result in a high percentage of “dead drops” which the player doesn’t want. - = Cooperative Action, Competitive Collection Combat will be highly cooperative, with weapons and simple skills intended to encourage the players to work together while fighting. Weapons like shields, healing staves, or bats will be almost exclusively cooperative in nature, and every weapon should have at least one effect which provides a boost to the player's allies which is greater than the boost it provides to themselves. Bosses should feel insurmountable without the help of other players. As a contrast to the highly cooperative nature of the combat, item collection, player leveling, and even some areas of traversal will be competitive in nature. We'll be looking to foster a sort of love-hate relationship between players; look to games like Four Swords and Munchkin for examples of this. While we'll need to be careful to balance the amount of interference players can exact on each other - remember that all the players are still working towards the same goal - we will still be putting in a number of systems to make sure the players don't get too close: Friendly Fire Players shouldn't have the ability to directly deal damage to each other, due to the high potential for griefing and uncooperative play this could lead to. However, players should still be able to interfere with their allies at-will - most specifically, during item collection. As such, we should allow players to apply knockback effects, as well as other detrimental effects such as slow, confused controls, or burning, while not necessarily applying damage. Player Death Death should be of relatively high consequence to the players. A player who dies on a run will be rendered unable to move, and a portion of their loot and stat-ups should jettison out, allowing other players to pillage their corpse. Players should be able to revive their fallen allies somehow, to support our co-op combat. This could also lead to a sort of reward for the player who revives their ally, as they will be able to steal a portion of the fallen's stats. Stretch Goals Complicated Upgrades Besides simple stat bonuses, I'd like to see a decent variety of complex power-ups. Examples to look at here would be bonus items in Risk of Rain or Isaac. We should avoid adding anything that the player has to actively use, but rare drops such as followers, auras, flight, or any sort of slight visual upgrade would be an excellent way to deliver peaks of discovery to the player, as well as allowing us to add some seriously funny upgrades. Alternate Playable Characters Unlocked periodically as players earn gold and complete challenges, alternate characters would be a relatively inexpensive way to add a lot of replayability to the game. Once we had the core system in place, adding additional characters would only require a new art asset and some changes starting stat values. Stat-UPs Based on the current state of the game, stat-ups have been reclassified to stretch ups. Player Characters have baseline stats at the start of a run, which can be improved over the course of the game through the use of pickups/enemy drops. These drops will most commonly increase movement speed, attack damage, and health, with rarer drops consisting of attack speed, weapon size, knockback, or potentially other more extreme changes. These will be the primary drop that players will be pursuing, as they will ALWAYS be something the player wants and needs. As such, we should opt for a large number of small bonuses, rather than a small number of large bonuses. A multitude of smaller bonuses will also help to ensure all players receive a relatively even distribution of total stats. Movement Speed The effects of movement speed bonuses will be among the most immediately obvious to the player, as well as the most useful across all aspects of gameplay: attacking, collecting, and evading, as well as pure traversal. Following this, we should make movement speed bonuses one of the most common. Health Although not as immediately apparent as the bonuses garnered from movement speed, Heath bonuses should be something that players should understand as intrinsically important. Health bonuses should be relatively common, although their magnitude, frequency, and whether they should affect current or only maximum health should all be carefully monitored to maintain difficulty. Attack Damage The third of the "basic" stat-ups is attack damage. These are simple, numerical bonuses to the total damage of each strike the player makes. Each weapon should have a value - based on its attack speed - that is multiplied by the number of attack-ups the player has collected to ensure that each weapon benefits equally from these bonuses. Weapon Size Simple enough. Increased weapon size will give the player an increased attack range. If weapons can be used to pick up dropped loot, then players will also gain an advantage in the collection aspect of the game. We should closely monitor this to make sure no player snowballs too far ahead of the others. Reductions to attack animation speed and increases to attack cooldown should be considered for balance reasons. Intentionally Ignored Stats These are stats that, while reasonable candidates for stat-up categories, have various reasons why they should not be implemented into early builds. * Attack Speed: Due to the high importance that attack cooldown holds, we should try to keep any changes to the cooldown between attacks to a minimum. We should increase the animation speed for the attack as we decrease cooldown between attacks, to make the effect more obvious to the player. These bonuses, if implemented, should be rare. * Damage Reduction: '''While defense is a reasonable and relatively common stat, its inclusion would make it more difficult to predict the total amount of damage players are taking on average. By keeping player defenses tied strictly to health, we can more easily scale enemy damage and healing effectiveness. '''Stretch Stats Here are some stats that I would like to see in a final build of the game, but will require much more work and consideration to properly implement, and as such should not see early builds. * Player Size: '''By modifying player size, we can change a lot of the fundamental interactions between players and enemies. Making a player smaller will increase their ability to evade attacks and projectiles, but will decrease the size of their attack arc. A larger player would be a large target, but would also be able to protect his allies in a larger area, were they to use a shield. Because neither scaling direction - growing or shrinking - will be the best choice for all players, we should include both. This will hopefully help to encourage the cooperative aspects of the game, as one player's trash can become another player's treasure. Slight changes to health, movement speed, and damage reduction should be considered as accompaniments to player size changes, to help control its effects in combat. As a side note, this would also open up the option for player-specific areas; eg. grates that small players can't pass over, or narrow hallways large players can't pass through. ''' Technicals Controls The primary supported controller scheme will be Xbox 360 controllers, although keyboard support will be offered. The base control scheme is as follows: Movement: Left Control Stick Rotate Character: Right Control Stick. When the right control stick isn't pressed, The player defaults to facing their current movement direction. Right Hand Weapon: Right Trigger. Right Hand Secondary: Hold Right Trigger Briefly Right Hand Tertiary: Hold Left Trigger Longer Left Hand Weapon: Left Trigger. Left Hand Secondary: Hold Left Trigger Briefly Left Hand Tertiary: Hold Left Trigger Longer Right Hand Equip/Drop Weapon: RB Left Hand Equip/Drop Weapon: LB The face buttons and d-pad on the controller are both intentionally left out. By mapping all of the players' primary actions to the shoulder buttons, players will be able to keep both thumbs on the joysticks at all times. This will allow players easier access to the constant movement that we're hoping to encourage. Map Generation Maps will be generated in a placed-tile format, with individual rooms being custom designed, and attacked together by static doors on each side. A lot of attention will need to be paid to the "drop rates" of specific rooms, and we'll need to be able to spawn specific combinations of rooms together, such as in areas near the start of the level, and areas leading up to a boss. The average level should be made up of roughly 14-20 rooms. Rooms have their own sub-page, listed below. Rooms Camera The Camera shouldn't need too much dynamic movement, as players should only be allowed to occupy a single room at a time. To prevent players from (overly) impeding the progress of the other players, a countdown should initiate once a majority(66%) of the players are all grouped at the exit. In a two person game, the players are responsible for getting each other to behave. Art and Aesthetics Low Poly, Geometric Style We'll be going with a low poly, 5-7 sided diamond based visual style, complemented by our impressive lighting system. Shapes will likely be untextured, allowing the bulk of our visual appeal to come from lighting and robust particle effects. Environments Environments are dark, cavelike pathways and tunnels. Ambient lighting and glow effects are used frequently to help liven up the atmosphere. Lights without associated physics bodies should be used to represent fog, wisps, and fireflies. Particle systems will be used to represent liquid flows like water or lava. Entities Characters will be extremely simple; Made of geometric shapes and fractured diamond shapes. Each entity will have roughly 15-40 faces, and will be generally limbless; this will allow us to avoid any complicated walking or swinging animations. Particles Particles are such a huge part of our game, they should almost be classified under the Primary Mechanics section. Every connecting strike to any enemy, player, or environment should spawn a small number or cubic debris, and any fatal strike should cause the object to explode into it's component parts. Physics should be partially taken into account, allowing players to interact with at least some of the fallen enemy bits. Depending on the type of killing blow, blocks should either crumble to the ground, explode outwards/to one side, or splash upwards towards the camera. As a stretch goal, we should try to add as much variation to the types of Voxel effects as possible. Camera The camera will likely be a slightly tilted overhead view, similar to isometric action titles like Bastion or Diablo. We probably want to stay far away from split screen, as having all players on a single screen will help encourage a cohesive experience. It should stay in a center point, between all players, and zoom in and out as the players create and close distance between each other. A maximum range between players should be considered, potentially even only spanning a single room. HUD We're going for a minimalistic HUD, with as clear and empty of a screen as possible. This means we'll have to be much more creative in conveying key information such as player/enemy health, but we'll be rewarded with the ability to place a much higher emphasis on in-game visuals. This will also help mitigate the need for multiple copies of each HUD for multiple players. Less immediately important information, such as the current dungeon floor or player gold counts, will be displayed between rooms and on the pause screen. Sound Sounds List Potential Issues Single-Player Mode Because so much of our design revolves around the concept of players working with and against each other, the single-player experience will likely suffer. AI companions are an option that could be considered, but will likely take up an inordinate of dev time for a system that our core audience will never experience. The game will also likely be significantly harder, due to the lack of cooperative skills. Its an area that we'll need to monitor closely. Spamming In many dungeon-crawler beat-em-ups, one of the biggest player complaints is the repetitive nature of combat. We'll be trying to avoid this by ensuring that enemies are challenging to the player mentally, and including combat options for the player besides "move forward and swing." Weapon charging is the first system to try to combat this, but careful attention needs to be paid to make sure players don't feel rewarded by spamming attacks. Predecessors Games from which we will be drawing inspiration include: * Gauntlet * Binding of Isaac * Rogue * Risk of Rain * Munchkin * Four Swords * Castle Crashers